Respect postgres.passwordSecretName in presence of rr.agentSandbox.externalSecret by ryanartecona · Pull Request #332 · tryretool/retool-helm

ryanartecona · 2026-06-12T23:30:37Z

In blueprints, we want the agentSandbox secrets to come from different places: jwt-public-key, jwt-private-key, and postgres-url from an agent-sandbox secret, but specifically the postgres password from the main retool secret, as that is the only one that gets auto rotated by e.g. RDS.

This allows agentSandbox.externalSecret to also be used with agentSandbox.postgres.passwordSecretName when both are present.

…ternalSecret

greptile-apps · 2026-06-12T23:33:54Z

Greptile Summary

This PR extends retool.agentSandbox.postgresUrlEnv so that when externalSecret.name supplies the postgres-url, a separately configured postgres.passwordSecretName (e.g. the main Retool secret auto-rotated by RDS) is also injected as PGPASSWORD. This enables the blueprint use-case where JWT keys and the postgres URL come from one external secret while the password comes from another.

Adds a conditional PGPASSWORD secretKeyRef block inside the $ext branch of retool.agentSandbox.postgresUrlEnv, mirroring the existing pattern already present in the $pg.host branch.
Bumps the chart to 6.11.1 and updates comments in both values.yaml copies to document the new combination.

Confidence Score: 4/5

The externalSecret path change is correct; the urlSecretName branch is left without equivalent passwordSecretName support, which could silently drop the password for users who pair those two options.

The new PGPASSWORD block in the externalSecret branch is logically correct and mirrors the existing host-path pattern. The concern is that the parallel urlSecretName branch still has no passwordSecretName support — a user storing a passwordless DSN via urlSecretName and setting passwordSecretName will silently get no PGPASSWORD at runtime.

charts/retool/templates/_helpers.tpl — specifically the urlSecretName branch around line 738

Important Files Changed

Filename	Overview
charts/retool/Chart.yaml	Patch version bump from 6.11.0 to 6.11.1 to reflect the bugfix change.
charts/retool/templates/_helpers.tpl	Adds PGPASSWORD env var support to the externalSecret branch of retool.agentSandbox.postgresUrlEnv; the urlSecretName branch gets no equivalent treatment, creating an asymmetry.
charts/retool/values.yaml	Comment-only update documenting that the postgres-url from externalSecret can omit the embedded password and use passwordSecretName instead.
values.yaml	Mirrors the same comment-only update as charts/retool/values.yaml.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[retool.agentSandbox.postgresUrlEnv] --> B{pg.url set?}
    B -- Yes --> C[AGENT_SANDBOX_POSTGRES_URL = plaintext url]
    B -- No --> D{pg.host set?}
    D -- Yes --> E{passwordSecretName?}
    E -- Yes --> F[PGPASSWORD from secret]
    E -- No --> G{pg.password?}
    G -- Yes --> H[PGPASSWORD plaintext]
    F --> I[AGENT_SANDBOX_POSTGRES_URL assembled from host/user/db]
    H --> I
    G -- No --> I
    D -- No --> J{pg.urlSecretName set?}
    J -- Yes --> K[AGENT_SANDBOX_POSTGRES_URL from secret - NO PGPASSWORD support]
    J -- No --> L{externalSecret.name set?}
    L -- Yes --> M[AGENT_SANDBOX_POSTGRES_URL from external secret]
    M --> N{passwordSecretName? NEW}
    N -- Yes --> O[PGPASSWORD from passwordSecretName secret]
    N -- No --> P[no PGPASSWORD]
    L -- No --> Q[Inherit backend postgres - PGPASSWORD from config.postgresql secret]

Comments Outside Diff (2)

charts/retool/templates/_helpers.tpl, line 701-702 (link)

The docblock says "plus a PGPASSWORD entry when assembling from fields" but after this PR, PGPASSWORD can also be emitted in the externalSecret path. The phrase "when assembling from fields" now understates the scope — callers reading this comment before the externalSecret branch won't expect PGPASSWORD to appear there.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!
charts/retool/templates/_helpers.tpl, line 738-743 (link)

urlSecretName branch silently ignores passwordSecretName

The externalSecret branch (just below) now respects passwordSecretName, but the urlSecretName branch does not. A user who stores a passwordless DSN in a Kubernetes secret via urlSecretName and sets passwordSecretName to provide the password separately will get no PGPASSWORD env var and a silent connection failure at runtime. The urlSecretName path could apply the same {{- if $pg.passwordSecretName }} block that was just added to the externalSecret path.

_{Reviews (1): Last reviewed commit: "bump patch" | Re-trigger Greptile}

…cretName the fromExternalSecret boolean was redundant with the existing Option-3 postgres.urlSecretName/urlSecretKey: 'read postgres-url from externalSecret.name' is identical to pointing urlSecretName at that same secret (urlSecretKey already defaults to postgres-url). drop the bespoke flag and the externalSecret postgres branch entirely, so externalSecret.name covers ONLY the JWT/encryption keys and never sources postgres. - remove rr.agentSandbox.postgres.fromExternalSecret (both values.yaml copies) - postgresUrlEnv: delete the externalSecret postgres branch; move the passwordSecretName PGPASSWORD support (#332) into the urlSecretName branch, so 'DSN from a secret + auto-rotated password from another secret' uses Option 3 - validateSecrets: drop the externalSecret term from $explicitPg; repoint both fail hints to postgres.urlSecretName - ci: test-agent-sandbox-enabled-option uses postgres.urlSecretName (Option 3) pointed at its JWT secret instead of the removed flag

…gres.urlSecretName); require encryption key (#331) * fix(rr): stop agentSandbox externalSecret.name from hijacking postgres; require its encryption key setting rr.agentSandbox.externalSecret.name (intended for the JWT keypair) silently (a) routed the agent sandbox postgres connection to that secret's postgres-url key and (b) coupled the encryption key to it. an existing deployment that just wanted to reuse its backend postgres crashed at runtime with getaddrinfo ENOTFOUND. - postgres now only reads from externalSecret when postgres.fromExternalSecret: true (default false); otherwise it inherits the backend's config.postgresql connection, even when externalSecret.name is set for the JWT - require the agent sandbox encryption key (validateSecrets, mirroring the JWT keys): the proxy derives the sandbox-iframe asset-token HMAC key from AGENT_SANDBOX_ENCRYPTION_KEY and throws when serving a sandbox without it (agent_executor/proxy/src/config.ts getAssetTokenHmacSecret), so 'optional' would surface as a green pod that fails at first sandbox use. fail loudly at render instead. - updated both validateSecrets fail hints to mention postgres.fromExternalSecret: true - values.yaml (both copies): add postgres.fromExternalSecret, mark encryptionKey required, note 64 hex - bump chart 6.11.1 -> 6.11.2; update ci fixtures to supply the now-required encryption key and add fromExternalSecret: true to the Option-4 sandbox fixture * Respect postgres.passwordSecretName in presence of rr.agentSandbox.externalSecret (cherry picked from commit 38304c0) * refactor(rr): replace postgres.fromExternalSecret with postgres.urlSecretName the fromExternalSecret boolean was redundant with the existing Option-3 postgres.urlSecretName/urlSecretKey: 'read postgres-url from externalSecret.name' is identical to pointing urlSecretName at that same secret (urlSecretKey already defaults to postgres-url). drop the bespoke flag and the externalSecret postgres branch entirely, so externalSecret.name covers ONLY the JWT/encryption keys and never sources postgres. - remove rr.agentSandbox.postgres.fromExternalSecret (both values.yaml copies) - postgresUrlEnv: delete the externalSecret postgres branch; move the passwordSecretName PGPASSWORD support (#332) into the urlSecretName branch, so 'DSN from a secret + auto-rotated password from another secret' uses Option 3 - validateSecrets: drop the externalSecret term from $explicitPg; repoint both fail hints to postgres.urlSecretName - ci: test-agent-sandbox-enabled-option uses postgres.urlSecretName (Option 3) pointed at its JWT secret instead of the removed flag * fix(rr): render blobStorage env onto the workflow worker the agentExecutor / snapshotRetention temporal activities run on the WORKFLOW_TEMPORAL_WORKER (registered in workflowsExecutor/onpremWorker) and read snapshot blob storage via getBlobStoreForSnapshots (RR_SNAPSHOTS_* with an RR_DEFAULT_* fallback). but gitServer.commonEnv was only injected onto the main backend and the standalone git-server pod, so the worker had no RR_DEFAULT_* and snapshot blob access failed there -- forcing operators to hand-plumb RR_SNAPSHOTS_* via env. include gitServer.commonEnv on the worker when rr.gitServer.enabled (no git-server host/port split -- the worker is a blob-storage client, not the git server). self-guards on rr.blobStorage being set, so it no-ops otherwise. * chore(rr): bump chart version to 6.11.3 (rebased past #333) --------- Co-authored-by: Ryan Artecona <ryanartecona@gmail.com>

ryanartecona added 2 commits June 12, 2026 12:10

Respect postgres.passwordSecretName in presence of rr.agentSandbox.ex…

38304c0

…ternalSecret

bump patch

ddb011f

JatinNanda mentioned this pull request Jun 12, 2026

fix(rr): decouple agentSandbox postgres from externalSecret (use postgres.urlSecretName); require encryption key #331

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Respect postgres.passwordSecretName in presence of rr.agentSandbox.externalSecret#332

Respect postgres.passwordSecretName in presence of rr.agentSandbox.externalSecret#332
ryanartecona wants to merge 2 commits into
mainfrom
ra/agent-sandbox-pgpassword

ryanartecona commented Jun 12, 2026

Uh oh!

greptile-apps Bot commented Jun 12, 2026 •

edited

Loading

Greptile Summary

Confidence Score: 4/5

Important Files Changed

Flowchart

Comments Outside Diff (2)

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Conversation

ryanartecona commented Jun 12, 2026

Uh oh!

greptile-apps Bot commented Jun 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Greptile Summary

Confidence Score: 4/5

Important Files Changed

Flowchart

Comments Outside Diff (2)

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

greptile-apps Bot commented Jun 12, 2026 •

edited

Loading